Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore template literals #14173

Closed
wants to merge 2 commits into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented Jul 11, 2017

First commit:

tools: ignore template literals for line length

The line length limitation applied by linting is intended to improve
readability. Unfortunately with template literals, practices used to get
around it can inhibit readability. For example:

    return `The "${name}" array must have a length of ${
           length}. Received length ${actual}`;

Configure the linter to ignore line length limitations for template
literals.

Second commit:

lib,test: remove linebreaks from template literals

Improve readability of template literals by removing some creative use
of line breaks.
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

tools test lib

The line length limitation applied by linting is intended to improve
readability. Unfortunately with template literals, practices used to get
around it can inhibit readability. For example:

    return `The "${name}" array must have a length of ${
           length}. Received length ${actual}`;

Configure the linter to ignore line length limitations for template
literals.
Improve readability of template literals by removing some creative use
of line breaks.
@Trott Trott added lib / src Issues and PRs related to general changes in the lib or src directory. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory. labels Jul 11, 2017
@nodejs-github-bot nodejs-github-bot added errors Issues and PRs related to JavaScript errors originated in Node.js core. tools Issues and PRs related to the tools directory. labels Jul 11, 2017
@AndreasMadsen
Copy link
Member

AndreasMadsen commented Jul 11, 2017

I normally don't care about the linter stuff but this I'm -1 on. Having 80+ lines in annoying for those who don't have a wide screen. And having a single exception for this one case I find very odd.

Surely the solution is to teach/enforce a better approach such as:

const s = `The "${name}" array must have a length of \
${length}. Received length ${actual}`;

or

const s = `The "${name}" array must have a length of` + 
          ` ${length}. Received length ${actual}`;

@vsemozhetbyt
Copy link
Contributor

FWIW, we already have exceptions for RegExps and URLs.

@Trott
Copy link
Member Author

Trott commented Jul 11, 2017

@AndreasMadsen An alternative might be to use http://eslint.org/docs/rules/template-curly-spacing to get rid of this irksome pattern.

On the "annoying for those who don't have a wide screen" thing: Do you fall into that category? I've often suspected that max-len solves a problem that used to be prevalent but is now largely imaginary. It would be more difficult for me to continue to believe that if there was confirmation that you or someone else active on the project works in an environment with an 80-char width limit.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 Question
1 nit

@@ -267,8 +268,8 @@ function error_test() {
expect: /\bSyntaxError: Invalid or unexpected token/ },
// do not fail when a String is created with line continuation
{ client: client_unix, send: '\'the\\\nfourth\\\neye\'',
expect: `${prompt_multiline}${prompt_multiline}'thefourtheye'\n${
prompt_unix}` },
expect: `${prompt_multiline}${prompt_multiline}'thefourtheye'\n` +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why split in this file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Splitting at \n made sense elsewhere as it made the template literal layout approximate its output, although I can see that maybe it's not needed here.

@@ -253,6 +253,5 @@ for (const u in formatTests) {
assert.strictEqual(actual, expect,
`wonky format(${u}) == ${expect}\nactual:${actual}`);
assert.strictEqual(actualObj, expect,
`wonky format(${JSON.stringify(formatTests[u])}) == ${
expect}\nactual: ${actualObj}`);
`wonky format(${JSON.stringify(formatTests[u])}) == ${expect}\nactual: ${actualObj}`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one could be mitigated by chopping down all args.

@refack
Copy link
Contributor

refack commented Jul 11, 2017

@refack refack closed this Jul 11, 2017
@refack refack reopened this Jul 11, 2017
@refack
Copy link
Contributor

refack commented Jul 11, 2017

Wrong button

@AndreasMadsen
Copy link
Member

AndreasMadsen commented Jul 11, 2017

On the "annoying for those who don't have a wide screen" thing: Do you fall into that category?

This is my normal setup:

skaermbillede 2017-07-12 kl 00 08 28

I'm sure there are ways I could get 10 chars extra but I don't think that is what we are talking about.


I don't mind 80+ lines when it is clear that no better alternative exists (such as URLs). However, in this case, I strongly believe better alternatives exist.

@refack
Copy link
Contributor

refack commented Jul 11, 2017

@AndreasMadsen could you please repost that in #14176. Personally I'd take 10 more chars 😺

@lpinca
Copy link
Member

lpinca commented Jul 12, 2017

I'm also -1 on this. As @AndreasMadsen said better alternatives exist.

@cjihrig
Copy link
Contributor

cjihrig commented Jul 12, 2017

Also -1

@jasnell
Copy link
Member

jasnell commented Jul 14, 2017

As much as I get annoyed by the 80 char limit, I'm in favor of keeping it. -1 on this.

@Trott
Copy link
Member Author

Trott commented Jul 15, 2017

Thanks, everyone! I'm going to close this as (obviously) there is not consensus and I don't intend to argue strenuously for this. I'll instead try to refactor more egregious formatting of template literals into things I find more readable and sensible. New indentation linting may force that anyway.

@Trott Trott closed this Jul 15, 2017
@Trott Trott deleted the ignore-template-literals branch January 13, 2022 22:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. lib / src Issues and PRs related to general changes in the lib or src directory. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants